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(57) Abstract: A packet-based communication system and method 
of call control that allows variable numbers of calls of potentially mul- 
tiple types (e.g., conventional and trunking calls) to proceed concur- 
rently over shared links of an IP network (100) without exceeding 
available bandwidth. Call counts are determined for one or more paths 
(160, 162, 164) between endpoints, defining numb^s of calls that are 
supportable by the one or more paths. The call counts may be es- 
tablished using a reservation-based method, whereby reservations of 
call units of bandwidth are requested (402) by a first host (e.g., zone 
controller (1 16)) on behalf of a second host (e.g., repeater (122)) and 
granted (408) or denied (416) by the network: based on the availability 
of the requested bandwidth. Then, upon the zone controller receiving 
(502) a call request, the zone controller grants (506), busies or denies 
(510) the request based on the path(s) needed for the call, the number 
of reserved call units associated with the path(s) and the amount of 
call units required to support the call. 
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METHODS FOR MANAGING BANDWIDTH 
IN A PACKET-BASED COMMUNICATION SYSTEM 



FIELD OF THE INVENTION 

5 This invention relates generally to communication systems and, more 

particularly, to packet-based communication systems. 

BACKGROUND OF THE INVENTION 

Communication systems typically include a plurality of communication units, 

10 such as mobile or portable radio units and dispatch consoles that are geographically 
distributed among various repeater sites and console sites. The communication units 
wirelessly communicate with the repeater sites and each other, and are often logically 
divided into various subgroups or talkgroups. Commimication systems may be 
organized as trunked systems, where a plurality of commimication resources is 

15 allocated amongst multiple users or groups by assigning the repeaters within a radio 
frequency (RF) coverage area on a call-by-call basis, or as conventional (non-trunked) 
radio systems where communication resources are dedicated to one or more users or 
groups. In trunked systems, or in mixed trunked and conventional systems, there is 
usually provided a central controller (sometimes called a "zone controller") for 

20 allocating communication resources among multiple sites. The central controller may 
reside within a single device or multiple devices and may be located at a fixed 
equipment site or may be distributed among the repeater or console sites. 

Traditionally, the repeater and console sites were linked via a circuit-switched 
architecture, through dedicated or on-demand circuits to a central radio system 

25 switching point ("central switch"). The circuits providing connectivity to the central 
switch required a dedicated wire for each endpoint (e.g., repeater site or console site) 
whether or not the endpoint was participating in a particular call. Often, the 
bandwidth (circuits) between endpoints were pre-provisioned for certain types of 
calls, for example for trunked calls and/or conventional calls. If a circuit was 

30 available for a trunking call, the zone controller reserved the circuit and granted the 
call. Otherwise, if a circuit was unavailable, the zone controller busied the call until 
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such time as resources became available. For conventional calls, circuits were pre- 
allocated from the conventional channels to the central switch. 

More recently, communication systems are using packet-switched networks 
where information that is to be communicated between endpoints is divided into 
packets and transported by various routers forming an Intemet Protocol (IP) network. 
For example, communication systems using packet-switched networks are described 
and claimed in U.S. Patent 6,141,347, titled "Wireless Communication System 
Incorporating Multicast Addressing and Method for Use'' and U.S. Patent Application 
Serial No. 09/464,269, titled "Methods for Implementing a Talkgroup Call in a 
Multicast IP Network," each of which is assigned to the assignee of the present 
invention and incorporated herein by reference in its entirety. Packet-switched 
networks are sometimes called "connectionless" networks because they do not 
provide dedicated bandwidth or circuits between endpoints, but rather permit 
communications between multiple endpoints to proceed concurrently over shared 
paths or connections. Due to the "connectionless" nature of packet-based networks, it 
is possible for call controllers to over-subscribe certain links. The problem is 
exacerbated in shared tranking and conventional systems because trunking 
controller(s) and conventional server(s), either alone or in combination may establish 
more calls than the network can support. 

Accordingly, there is a need for methods of call control in a packet-based 
communication system that provides for establishing calls over shared links of an IP 
network without exceeding available bandwidth. Advantageously, the methods of call 
control will provide for managing bandwidth/call counts for different types of calls, 
including but not limited to trunking, conventional, telephony and data calls; and the 
methods will include a reservation-based method of call control that may be utilized 
by zone controllers or other host devices of a communication network. The present 
invention is directed to satisfying these needs. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing and other advantages of the invention will become apparent 
upon reading the following detailed description and upon reference to the drawings in 
which: 

5 FIG. 1 is a block diagram of a packet-based commimication system according 

to the invention; 

FIG. 2 is a flowchart of a method of call control in a packet-based 
communication system according to the invention; 

FIG. 3 is a block diagram useful for illustrating physical and virtual 
10 connections between core routers of a multi-zone packet-based communication 
system; 

FIG. 4 is a flowchart showing a method of obtaining reservations of call 
counts in a packet-based communication system according to the invention; and 

FIG. 5 is a flowchart showing a method of managing call requests based on 
15 pre-established reservations of call counts according to the invention. 

DESCRIPTION OF PREFERRED EMBODIMENTS 

The following describes a packet-based communication system and method of 
call control that enables variable numbers of calls of potentially different types to be 
20 estabUshed over shared links of an IP network without exceeding available 
bandwidth. The following further describes a reservation-based method of 
determining call counts, or call units of bandwidth, that maybe used to support calls 
between participating devices of a single or multi-zone packet-based communication 
network- 

25 In one embodiment of the present invention, there is provided a method of call 

control in a communication system using a packet network for distributing packets 
between endpoints. The method comprises determining, for one or more paths 
between endpoints, a corresponding one or more call coimts defining respective 
numbers of calls that are supportable by the one or more paths. The call counts may 

30 be apportioned between first and second types of call (e.g., between trunking and 
conventional calls). Upon receiving call requests that require use of one or more 
paths, the call requests are granted if they do not exceed the call counts associated 
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with the one or more paths. Optionally, the call requests may be denied or busied if 
they exceed the call counts associated with the one or more paths or they may be 
granted by borrowing against call counts apportioned to a different type of call. 

In another embodiment of the present invention, there is provided a method of call 
5 control in a mixed trunking and conventional communication system using a packet 
network for distributing packets between endpoints for varying nxmibers of calls. The 
method comprises determining, for at least one path between endpoints, a call count 
defining a number of calls that is supportable by the path, which call count is 
apportioned between a trunking allocation and a conventional allocation. Upon 

10 receiving call requests for trunking and conventional calls, the call requests are 

granted if they will result in a number of active trunking calls that does not exceed the 
trunking allocation and a number of active conventional calls that does not exceed the 
conventional allocation. Optionally, the call requests for trunking or conventional 
calls are denied or busied if they will result in a number of active trunking or 

15 conventional calls that exceed the respective trunking and conventional allocations. 
As another option, requests for trunking calls may be granted even if it will result in a 
number of active trunking calls that exceeds the trunking allocation, if there is 
sufficient available conventional allocation that may be borrowed to support flie 
trunking call; or vice versa. As still another option, trunking calls may be granted if 

20 they will result in a number of active trunking calls that exceeds the trunking 
allocation and if there is, at a tune of the call request, insufficient available 
conventional allocation that may be borrowed to support the trunking call, by pre- 
empting one or more active conventional calls as needed to sufficiently increase the 
available conventional allocation to an amount that may be borrowed to support the 

25 trunking call, or vice versa. 

In still another embodiment of the present invention, there is provided a 
communication system using a packet network for distributing packets between 
endpoints. A controller determines, for at least one path between endpoints, a call 
count defining a number of calls that is supportable by the path. The call count may 

30 be apportioned between different types of calls (e.g., trunking, conventional, 
telephony and/or data calls). The path(s) may include, for example, trunking or 
conventional repeater site links, console site hnks or links between different 
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communication zones. The controller grants, denies or busies call requests, possibly 
of the dififerent types without exceeding the call count(s) associated with the path(s). 

In yet another embodiment of the present invention, there is provided a method of 
obtaining, by a first host device (e.g., zone controller), reservations of call units of 

5 bandwidth on behalf of at least a second host device (e.g., repeater and/or other host 
devices) that may require use of bandwidth. The method comprises the first host device 
requesting a reservation of one or more call units of bandwidth for a path of a packet 
network communication system. One or more network devices (e.g., routers of the 
network) determine the availability of the requested bandwidth and grant (or deny) the 

10 reservation based on the availabiUty of the requested bandwidth. Optionally, the first 
host may request additional call units of bandwidth if the reservation is granted or 
fewer call units of bandwidth if the reservation is denied, until such time as the first 
host is satisfied with the number of call units of bandwidth that are reserved for the 
path. Once a reservation has been obtained, the network devices may upwardly or 

15 downwardly adjust the reservation based on changes in the network such as link 
failures and the like. 

In still yet another embodiment of the present invention, there is provided a 
method of managing call requests based on pre-established reservations of call units. 
- The method comprises a first host device (e.g., zone controller) reserving one or more 

20 call imits of bandwidth for a path of a packet network communication system. Upon 
receiving a call request that requires use of the path, the zone controller grants the call 
request if there are sufficient reserved call units to support the call. Thereafter, the 
call may proceed by sending, fi-om a second host device (e.g., repeater), a message 
that is distributed over the number of units of bandwidth needed for the call, and the 

25 zone controller may adjust the number of reserved call units accordingly to manage 
additional call requests. 

Turning now to the drawings and referring initially to FIG. 1, there is shown a 
packet-based communication system (or "network") 100 comprising a plurality of sites 
102, 104, 106 that are logically coupled, via respective router elements 108, 110, 112 

30 to a core router element 114. The router elements 108-1 14 may be embodied in 
separate physical devices, for example, 3Com '"NetBuilder" series routers, or 
combinations of such devices. For convenience, the router elements will hereinafter 
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be referred to as "routers." The core router 1 14 is coupled to a zone controller 1 16 
having a processor 118 (such as a microprocessor, microcontroller, digital signal 
processor or combination of such devices) and a memory 120 (such as volatile or non- 
volatile digital storage devices or combination of such devices). In one embodiment 
of the present invention, the zone controller 116 manages and assigns infrastructure 
bandwidth (or "call units") between endpoints of the communication system for 
routing payload (voice, data, video, etc.) and/or control messages that are to 
distributed between and among the various sites 102, 104, 106. 

As shown, the communication system 100 is a mixed trunking and 
conventional system. Site 102 includes a plurality of repeaters 122, 124, 126 
("trunking repeaters") that are assigned on a call-by-call basis to communication units 
148, 150 within the radio frequency (RF) coverage area of site 102. Site 104 similarly 
includes a plurality of trunking repeaters 130, 132, 134 that are assigned on a call-by- 
call basis to communication units 152, 154, 156 within the coverage area of site 104. 
Site 106 includes a plurality of conventional repeaters 170, 172 that wirelessly 
communicate with commimication units (not shown) in their coverage area via 
dedicated RF channels. The conventional repeaters 170, 172 are linked to the console 
site 106 by a conventional server 174. 

The communication units 148-156 (sometimes called "subscriber units") may 
comprise mobile or portable wireless radio units and may be arranged into talk groups 
having corresponding talk group identifications as known in the art. Any number of 
talk groups having corresponding talk group identifications can be established within 
the system 100. In FIG. 1, for example, two separate talk groups are shown, 
identified by labels "A" and "B." Talk group "A" at least includes the 
communication units 150, 152, 154 and talk group "B" at least includes the 
communication units 148, 156. The communication system 100 may also support 
point-to-point calls, for example, between communication units 148 and 152. 

Generally, the repeaters at sites 102, 104 communicate, via wireless 
communication resources 144, 146 with the conamunication units 148-156. Suitable 
Vidreless communication resources 144, 146 are multiple RF (radio frequency) 
channels such as pairs of frequency carriers, time division multiple access (TDMA) 
slots, code division multiple access (CDMA) channels, or any other RF transmission 
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media. In the case where the communication resources comprise RF channels, it is 
common to assign separate channels and/or separate repeaters for different types of 
commimication traffic. Thus, the repeaters at the various sites 102, 104 may comprise 
control channel repeaters, voice channel repeatCTS and/or link repeaters. For 

5 convenience, the terai "repeater site" or simply "base site" will be used hereinafter 
instead of referring specifically to the repeater(s) at a particular site. The repeaters 
122, 124, 126 are coupled, via Ethemet 128 to an associated router 108 and the 
repeaters 130, 132, 134 are coupled, via Ethemet 136 to router 110. 

Site 106 includes a plurality of dispatch consoles 138, 140 that are coupled via 

10 Ethemet 142 to router 112 and defines a "console" site. Consoles 138, 140 may 

comprise wireless or wireline consoles. Console positions 138, 140 can affiliate with 
either, or both talkgroups "A" and "B" and, accordingly, maybe considered members 
of both talk groups "A" and "B." In the illustrated embodiment, the console site 
includes a conventional server 174 coimected to conventional repeaters 170, 172. As 

15 will be appreciated, conventional repeaters may be located at the repeater sites 102, 
104 instead of or in addition to the console site 106. Of course, conventional 
repeaters may be eliminated entirely to define a pure trunking system. Moreover, it 
will be appreciated that a repeater site may include console positions, and vice versa. 

Practitioners skilled in the art will appreciate that the network 100 may include 

20 various other communication devices not shown in FIG. 1 . For example, the network 
100 may include wireline communication device(s), site controller(s), comparator(s), 
telephone interconnect device(s), internet protocol telephony device(s), call logger(s), 
scanner(s) and gateway(s). Generally, such communication devices may be either 
sources or recipients of payload and/or control messages routed through the network 

25 100. These devices are described briefly below. 

A site controller is a device having a processor (such as a microprocessor, 
microcontroller, digital signal processor or combination of such devices) and a 
mCTiory (such as volatile or non-volatile digital storage devices or combination of 
such devices), that may be located at a particular site. A site controller may be used 

30 to control the communication of payload and/or control messages between repeater(s) 
at a particular site. A site controller may also control communications between &e 
r€peater(s) and their associated router. In one CTobodiment, for example, a site 
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controller sends IGMP Leave and Join messages to a router associated with a 
particular site to enable the repeater(s) at that site to receive payload and/or control 
messages addressed to particular multicast group address(es). 

A comparator (or "voter") is a device, usually connected by wireline to 
various receivers (e.g., different repeaters) receiving different instance(s) of a 
particular message or signal (e.g., from a subscriber radio unit). The comparator 
receives and compares among the different instances of the signal that may be 
received by the different receivers, and produces an output message that is comprised 
of either an entire message from one of the receivers or a composite message 
comprised of segments of the message received from one or more of the receivers. 
Each message may be comprised of a plurality of message frames. 

A scanner is a receiver that is adapted to monitor message transmissions from 
communication devices such as mobile or portable wireless radio units, consoles, 
repeaters, and the like. In one mode of operation, for example, a scanner scans the 
radio spectrum for the purpose of finding and, optionally, locking on to carrier 
frequencies containing message transmissions. Scanners are sometimes used by 
parties that are not intended recipients of the message transmissions and thus may or 
may not be members of a particular talkgroup for which the message transmissions 
are intended. 

A telephone interconnect device is a network-based device that provides voice 
transcoding services between mobile and land line subscribers when invoking full 
diq)lex telephone caUs between those two subscribers. A transcoding service is 
required, for example, when a mobile subscriber using ACELP vocoding requests a 
call to a subscriber in the public switched telephone networic (PSTN) using 64-kilobit 
per second PCM vocoding. 

An internet protocol telephony device comprises a telephone that transports 
voice and/or control messages over a LAN to a telephony gateway box, which 
interfaces multiple (LAN based) phones and converts the IP control and audio packets 
back into the format of the local PSTN. More generally, a gateway device is one that 
provides voice and control translation services between two dissimilar communication 
systems. For example, a gateway device would be required if an APCO Project 25 
compliant system were to be connected to a GSM system. Other services such as 
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feature translation, authentication, authorization and encryption could also be 
provided by a gateway device. 

A call logger is a networked based device that records packetized voice 
talkgroup and private calls in a public safety system. A call logger could also record 
data calls. A call logger device typically stores the voice payload in its native format 
(i.e. vocoded audio). When it is desirable to playback the voice conversation at a later 
time, the call logger retrieves and decodes all packets which boimd the call in 
question. 

In one embodiment, the repeaters 122, 124, 126 and router 108 at site 102, the 
repeaters 130, 132, 134 and router 110 at site 104, the repeaters 170, 172, 
conventional server 174, consoles 138, 140 and router 1 12 at site 106, the core router 
114 and zone controller 1 16 are all IP host devices that are able to send and receive IP 
datagrams between other host devices of the network. Each host device has a unique 
IP address. The host devices include respective processors (which may comprise, for 
example, microprocessors, microcontrollers, digital signal processors or combination 
of such devices) and memory (which may comprise, for example, volatile or non- 
volatile digital storage devices or combination of such devices). The routers 108-1 14 
are specialized or general purpose computing devices configured to receive IP packets 
or datagrams fi-om a particular host in the communication system 100 and relay the 
packets to another router or another host in the communication system 100. 

For example, a typical multicast communication begins with a sourcing host 
(e.g., repeater 126) receiving a call request from a conmiunication unit 150. For 
purposes of the present example, assume that the call request is for a talk group call 
("talk group A"). The repeater 126 forwards the call request to the zone controller 
116 and, based on mobility and talk group affiliations of the communication units, the 
zone controller 116 determines which endpoints need to participate in the call. Thus, 
for talk group A, the zone controller mi^t determine that repeater 126 at site 102, 
repeater 132 at site 104 and consoles 138, 140 at site 106 are the endpoints for the 
call The zone controller 116 forwards a multicast group address to those endpoints, 
via the core router 1 14 and local routers 108, 1 10, 1 12. The endpoints send Mtemet 
Group Management Protocol (IGMP) Join messages to their respective local routers, 
which are forwarded to the core router 1 14 to form a spanning tree of router interfaces 
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logically connecting the participating hosts. In the present example for talk group A, 
the spanning tree of router interfaces would include links 160, 162, 164 between the 
local routers and the core router. The sourcing host sends payload (e.g., audio, video, 
etc.) from the communication unit on the muhicast group address, which payload then 
may be received by participating hosts having successfully joined the multicast group 
address. 

Additionally, the conventional server 174 may grant conventional calls, 
concmrently with the trunking calls, that require use of the shared links 160, 162 or 
164. Heretofore, it has possible for the zone controller 1 16 and conventional server 
1 74, either alone or in combination, to grant more calls than the network can support. 
Although any of the shared links are susceptible for oversubscription, repeater site 
links (e.g., links 1 60, 162) are historically not a concern because they are sized to 
accommodate worst case loading scenarios. That is not the case, however, for console 
site links (e.g., link 160) and inter-zone links (e.g., between core routers in different 
zones, not shown in FIG. 1) because, for practical reasons, they are not sized to 
accommodate worst case loading scenarios. As an example. Motorola's 
S^IART20^E™ communication systems may include consoles sites with up to 30 
consoles each accommodating up to 64 calls. In such case, it is economicaUy 
impractical to size the console site link to accommodate 1,920 (i.e., 64 x 30) calls. 
Rather, the link is sized to accommodate a number of calls that is reasonable, within 
the budget constraints of the system. For puiposes of illustration, suppose a console 
site link (e.g.. link 160) is sized to accommodate 100 call units of bandwidth. In such 
case, it is possible for trunking calls granted by the zone controller 1 16 alone, for 
conventional calls granted by the conventional server 174 alone, or for a combination 
of trunking and conventional calls granted by the zone controller 116 and 
conventional server 174, respectively, to use greater than 100 call units of bandwidth 
at any given time on the console site link 160. 

FIG. 2 is a flowchart illustrating a method of call control that allows for 
establishing calls over shared links of an IP network without exceeding available 
bandwidth. At step 202, call count(s) (e.g., call units of bandwidth) are detemiined 
for one or more paths between endpoints of a communication system. The one or 
more paths comprise virtual connections between endpoints, through the packet 
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network. In one embodiment, the call counts are pre-configured by the system 
user/operator or zone controller according to the number of call units that are 
supportable over the different links. The call covmt(s) are stored in the memory 120 
of the zone controller 116 and may be changed, as needed, as system parameters 

5 change. In one embodiment, the zone controller periodically requests from the routers 
of the packet network, a currently supportable number of calls for each respective 
path and reduces or adds to call coimts accordingly. For example, call counts may be 
reduced dynamically in the event of link failures or outages in the system. 

In one embodiment, call counts are determined for console site links or inter- 

10 zone links, because those links have the most need for call control. However, as will 
be appreciated, call counts may be determined for links to any fixed equipment site(s), 
including repeater site links. For convenience, an example call count of 100 units of 
bandwidth is presumed to be established for the link 160 between the core router 1 14 
and the console site router 1 12. That is, at step 202, for purposes of the present 

15 example, it has been determined that 100 units of bandwidth are supportable by the 
link 160, which call units may be used by a variety of different types of calls. 

Optionally, at step 204, portions of the call count(s) may be allocated for 
differrat types of calls. In one embodiment, for example, a trunldng allocation is 
reserved for trunking calls and a conventional allocation is reserved for conventional 

20 calls in a mixed trunking and conventional system. Altematively or additionally, 

allocations may be determined for telephony, data or generally any other type of calls. 
The allocations may be determined in any manner, for example, by designating 
numbers or percentages of the call count for the different types of calls. In one 
embodiment, the sum of the allocations for different types of calls does not exceed the 

25 call count(s) for any link. Thus, for example, if the call count of 100 call units of 
bandwidth for link 160 is to be apportioned between trunking and conventional calls, 
70 call units might be reserved for trunking calls and 30 call units reserved for 
conventional calls. 

At step 206, the zone controller 116 receives call request(s) that require use of 
30 one or more paths. The requests may possibly be for different types of calls (e.g., 
trunking, conventional, telephony and/or data calls). In one embodiment, the 
conventional server will request call bandwidth to specific sites firom the zone 
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controller 116 whenever it wants to establish a conventional call. For each request, at 
step 208, the zone controller 1 16 determines every inter-zone and/or console link(s) in 
the path and determines if the call request can be granted without exceeding the call 
count(s) (or, if applicable, without exceeding the appropriate type allocation) 
associated with those links. If so, the zone controller 1 16 grants the call request at 
step 210. Thus, continuing the present example with respect to the console site link 
160, the zone controller will grant call requests for trunking calls if granting the 
request will result in no greater than 70 call units of bandwidth being used for active 
trunking calls, and similarly will grant call requests for conventional calls if granting 
the request will result in no greater than 30 call units of bandwidth being used for 
active conventional calls. For paths requiring inter-zone links, with links in different 
communication zones, the zone controllers in each respective zone communicate 
amongst themselves to establish the nec^sary call count(s). 

Optionally, at step 212, in the case where the call count is divided into 
allocations for different types of calls (e.g., trunking and conventional calls), and 
where the call request is for a certain type of call that can not be granted without 
exceeding its associated type allocation, the zone controller may "borrow" 
allocation(s) from different types of calls. Thus, continuing the present example, if 
the zone controller receives a request for a trunking call that, if granted, would result 
in active trunking calls using greater than 70 call units of bandwidth, it may be 
desirable to borrow call units reserved for conventional calls. If it is not desired to 
borrow call units reserved for the other type, the call may be busied at step 218 until 
such time as there are available call units that will support the call, or the call request 
may be denied at stqp 222. 

Conversely, if it is desired to borrow call units reserved for another type call, 
the zone contixiller determines at step 214 if there is suflBcient aUocation of call units 
of the oflier type available that would support the call request. If so, the zone 
controller borrows the allocation at step 216 and proceeds to grant the call request at 
step 210. Thus, in the present example, if 30 caU units of bandwidth are reserved for 
conventional calls and 20 are being used at the time of the trunking call request, 10 
call units of the conventional allocation are eligible to be borrowed for the trunking 
call. If that is sufiBcient to support the tiimking call, the zone controller may grant the 
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tnmking call and, for the duration of the trunking call, reduce the conventional 
allocation. Conversely, as will be appreciated, portions of the trunking allocation 
might also be borrowed to support conventional call requests. 

As another option, at step 220, if it is desired to borrow call units from another 

5 type but there is not enough available call units of the other type that would support 
the call, the zone controller may pre-empt active calls of the other type as needed to 
sufficiently increase the available allocation to an amount that may be borrowed to 
support flie call request. For example, upon receiving a request for a trunking call, 
where granting the call request would result in exceeding the trunking allocation and 

10 where the available conventional allocation is not enough to support the call, one or 
more active conventional calls may be pre-empted until such time as there is enough 
available conventional allocation that may be borrowed to support the call. At step 
214, once there is sufficient available allocation of the other type, the allocation is 
borrowed at step 216 and the call request is granted at step 210. 

15 As still another option, if it is desired to borrow call units from another type 

but there is not enough available call units of the other type that would support the 
call, and it is not desired to pre-empt active calls of the other type, the call may be 
biisied at step 224 until such time as there are available call units of either type that 
Avill support the call, or the call request may be denied at step 226. 

20 FIG. 3 illustrates a packet-based communication system 300 including zone 

controllers in multiple zones interconnected by various routers. As shown, there are 
four communication zones 302, 304, 306, 308, each having an associated zone 
controller and core router. Zone 302 includes zone controller 3 10 ("ZC 1") and core 
router 318 ("CR 1"); zone 304 includes zone controller 312 ("ZC 2") and core router 

25 320 ("CR 2"); zone 306 includes zone controller 314 ("ZC 3") and core router 322 
("CR 3'0; and zone 308 includes zone controller 316 ("ZC 4") and core router 324 
("CR 4"). Physical Unks between CR 1 , CR 2, CR 3 and CR 4 are denoted by 
reference numerals 326-332. A virtual link between CR 1 and CR 4 is denoted by 
reference numeral 330. For convenience, only zone controllers, routers and inter-zone 

30 links are shown in FIG. 3, although it will be appreciated that each communication 
zone may include repeater/base station(s), console(s), site controller(s), 
comparator/voter(s), scanner(s), site controlleT(s), telephone interconnect device(s) or 
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internet protocol telephony device(s), local router(s) and links between such devices, 
and each device may be a source or recipient of IP packets routed within the same 
zone or between different zones. 

The core routers CR 1-4 and the local routers of each zone (not shown in FIG. 
3) respond to addressing information in the IP packets received to properly route the 
packets to their intended destination. In accordance with internet protocol, the DP 
packets may be designated for unicast or multicast communication. Unicast is 
conmiunication between a single sender and a smgle receiver over the network. 
Multicast is communication between a single sender and multiple receivers on a 
network. Each type of data communication is controlled and indicated by the 
addressing information included in the packets of data transmitted in the 
communication system 100. For a unicast message, the address of the packet 
indicates a single receiver. For a multicast communication, the address of the packet 
indicates a multicast group address to which multiple hosts may join to receive the 
multicast communication. In such case, the routers of the network replicate the 
packets, as necessary, and route the packets to the designated hosts via the multicast 
group address. 

As described in relation to FIG. 2, a method of call control may use call 
counts, or call units of bandwidth between different endpoints of the communication 
system, managed by the zone controllers. CaU counts may be allocated for different 
types of calls (e.g., trunking and conventional calls) for different possible paths 
between endpoints and then, call requests are granted, denied or busied, as appropriate 
based on the availability of the call units of bandwidth and/or the type of the call. As 
may be observed in FIG. 3, paths between zones may characterize different, 
alternative physical links. For example, packets that are to be routed between CR 1 
and CR 4 may travel via physical links 326, 328 or alternatively, by physical links 
330, 332. Due to the nature of packet switched networks, the zone controllers do not 
necessarily know (or care) which physical links will be used. Rather, the routers of 
the network determine the path that will be taken through the network, independent of 
the zone controllers. Accordingly, in one embodiment of the invention, the zone 
controUers determine call counts for virtual paths between zones (e.g., link 334, 
between CR I and CR 4), which may or may not coincide with actual physical links. 
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FIG. 4 shows a method of a first host device establishing call count 
reservations according to one embodiment of the invention. The flowchart of FIG. 4 
presumes that reservations are being established for a single path of a packet network 
communication system. The path comprises a virtual path between any endpoints 

5 (host devices) of a packet network conmiunication system, including intra-zone or 
inter-zone paths (e.g., path 334). As will be appreciated, however, the steps of FIG. 4 
may be repeated as often as necessary to establish call count reservations for multiple 
paths. The steps of FIG. 4 are implemented, where applicable, using stored software 
routines within the first host device and/or one or more network devices (e.g., 

10 routers). 

The flowchart begins at step 402, with a first host device requesting a 
reservation fix>m the network of one or more call units of bandwidth for the path. The 
reservations are requested by the first host device on behalf of other host devices that 
may need bandwidth to participate in later call(s). For example, in one embodiment, 

15 the first host device comprises a zone controller (e.g., zone controller 116) that 
requests reservations of call units eligible to be used by other host devices (e.g., 
repeaters, consoles, etc.) in its communication zone. In one embodiment, the 
reservations of call units are requested using standard RSVP signaling between the 
zone controller 116 and the routers of the network, upon start-up of the zone 

20 controller 116, when the zone controller first commimicates with zone controllers of 
other communication zones. Alternatively or additionally, the reservations of call 
imits may be requested upon affiliations being received fi-om commimicatian units 
that are homed to different zones. For example, upon a radio homed to a second zone 
afBliating with a first zone, the zone controller associated with the first zone could 

25 make reservations between itself and the zone controller associated with the second 
zone. Preferably, in either case, reservations are requested so that they may be 
determined by the zone controller prior to receiving any call requests firom 
participating host devices. Altematively, reservations may be requested dynamically, 
on a call-by-call basis but in practical effect, RSVP signaling generally takes too long 

30 to be done for each call. 

At step 404, one or more network devices deteraiine the availability of the 
requested bandwidth. If the requested bandwidth is available (step 406), the network 
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grants the reservation at step 408, thereby yielding one or more reserved call units for 
the path. In one embodiment, granted reservations obtained by the first host device 
are associated with one or more multicast group addresses that are not used for actual 
calls, as will be described in greater detail in relation to FIG. 5. Otherwise, if the 
requested bandwidth is unavailable, the network denies the reservation at step 418. 

Optionally, after having a reservation request granted, the first host device 
may request additional call unit(s) of bandwidth at step 410. For any such requests, 
the network devices determine the availability of the requested call unit(s) at step 404 
and, if they are available, grant reservation(s) for the incremental call units. For 
example, it is envisioned that a zone controller may wish to establish reservations for 
ten call units of bandwidth for a particular link. One manner in which this may be 
accomplished is to submit, one at a time, ten separate requests for single units of 
bandwidth. Depending on availability of the requested bandwidth, there may result 
ten separate reservations of one unit of bandwidth. Of course, the same effective 
bandwidth reservation might be achieved by submitting, for example, five requests for 
two units of bandwidth, or a single request for ten call imits of bandwidth but the 
larger the request, the greater likelihood that the request will be denied. 

Optionally, after having a request for multiple units of bandwidth denied, the 
first host device may request fewer number(s) of call units at step 41 8. If so, the 
network devices determine the availability of the revised number of requested call 
unit(s) at step 404 and, if they are available, grant reservation(s) for the revised 
number(s) of call units. If the revised number of requested call unit(s) is unavailable, 
the request is denied and the first host device may submit further revised requests 
until such time as a reservation is granted for the revised number of requested call 
units, or until the revised request comprises a request for a single call unit and that 
request is denied. 

At step 412, if there is a change in network availability, for example, if a link 
breaks (or is fixed), the network devices may adjust the reservation upwardly or 
downwardly, as appropriate, at step 414. Alternatively, the network devices may 
break the reservation in response to a change in network status and notify the 
requesting host device (e.g., zone controller), thereby allowing the requesting host to 
submit additional requests in an attempt to re-establish reservations. 
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Now turning to FIG. 5, there will be described a method of managing call 
requests based on pre-established reservations of call counts according to the 
invention. That is, the flowchart of FIG. 5 presumes that reservations of call omits 
have been statically determined, by a first host (e.g., zone controller) prior to 

5 receiving any call requests. 

The steps of FIG. 5 are implemented, where applicable, using stored software routines 
within the first host and/or one or more participating host devices. At step 502, the 
zone controller receives a call request firom a host device desiring to participate in a 
call. For example, with reference to FIG. 1, the zone controller 1 16 might receive a 

10 call request firom repeater 126. Typically, call requests firom repeaters are initiated by 
wireless communication units (e.g., communication imit 150) within the repeater's 
coverage area. Historically, wireless commxmication units are not IP host devices 
and, as such, do not directly communicate with the zone controller. Nevertheless, it is 
anticipated that some commimication systems will extend IP host fimctionality to the 

15 conmiunication units 148-156, in which case the commimication units 148-156 may 
directly submit call requests to the zone controller. 

At step 503, the zone controller determines the path(s) and the required call 
vinit(s) of bandwidth needed to support the call. For purposes of the present example, 
assume that the call request is for a talk group call ("talk group A")- Based on 

20 mobility and talk group affiliations of the commxmication units, the zone controller 
116 determines which endpoints need to participate in the call, which path(s) between 
endpoints are needed to support the call and the call units of bandwidth needed to 
support the call. Thus, for example, the zone controller mig;ht detamine that r^eater 
126 at site 102, repeater 132 at site 104 and consoles 138, 140 at site 106 are the 

25 endpoints for the call, paths 160, 162 and 164 are needed to support the call and one, 
one, and two units of bandwidth are needed for the respective paths. Generally, the 
number of units of bandwidth needed for each path is a fimction of the number of 
endpoints served by that path and the type of call (e.g., audio vs. video caUs). As will 
be appreciated, the endpoint(s) participating in the call may include host devices in 

30 other commimication zones, in which case the path(s) between endpoints will include 
inter-zone links (see FIG. 3) as well as intra-zone link(s). 
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At Step 504, the zone controller determines whether the call units of 
bandwidth reserved for the path(s) are sufficient to support the call, that is if the 
number of units of bandwidfli needed for the call does not exceed the units of 
bandwidth reserved by the 2»ne controller. If there are sufficient reserved call units to 
5 support the call, the zone controller grants the call request at step 506. In one 
embodiment, upon granting a call request, the zone controller 1 16 forwards a 
multicast group address to the participating endpoints, via the core router 1 14 and 
local routers 108, 1 10, 1 12. The endpoints send Internet Group Management Protocol 
(IGMP) Join messages to their respective local routers, which are forwarded to the 

10 core router 1 14 to form a spanning tree of router interfaces logically connecting the 
participating hosts. In the present example for talk group A, the spanning tree of 
router interfaces would include links 160, 162, 164 between the local routers and the 
core router. Then, at step 508, the devices having joined the multicast group address 
participate in a call, thereby using at least a portion of the call units of bandwidth that 

15 were reserved by the zone controller. Thus, continuing the present example, the 

repeater 126 at site 102 may send a message (e.g., audio, video, etc.) on the multicast 
group address, which message is distributed over the number of units of bandwidth 
needed for the call and may be received by the repeater 132 at site 104 and the 
consoles 138, 140 at site 106 once they have successfully joined the multicast group 

20 address. 

In one embodiment, the multicast group address(es) used for the actual calls 
differs firom flie address(es) that the reservations are on. Thus, for example, the zone 
controller may have obtained reservations for ten call units for a particular path, 
associated with a corresponding ten multicast grovtp addresses. However, upon 

25 granting call request(s), the zone controller forwards different multicast group 
addresses to the participating devices. 

Altranatively, if there are sufficient call units of bandwidth avalable for some 
but not all of the required paths, the zone controller may send the multicast group 
address to only those endpoints of the patiis where sufiBcient bandwidth is available. 

30 Tha-eafter, upon those endpoints joining the multicast group address, a spanning tree 
of router interfaces may be formed that includes the patii(s) where sufficient 
bandwidth is available but does not include paths where sufficient bandwidth is not 
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available. In either case, at step 508, the devices having joined the multicast group 
address participate in a call, thereby using at least a portion of the call units of 
bandwidth that were reserved by the zone controller. 

At step 512, the zone controller adjusts the number of reserved call units 

5 accordingly, based on the niunber of reserved call units that are "in use." Thus, for 
example, if ten call units of bandwidth were reserved for a particular path, and call 
requests have been granted that require two units of bandwidth, the zone controller 
will consider that it has eight remaining reserved call units. Conversely, the number 
of reserved call units may be upwardly adjusted as active calls are terminated. 

10 If, at step 504, the zone controller determines that there are not enough 

reserved call imits of bandwidth to support a call request, the call is busied or denied 
at step 510. Altematively, although not shown in FTG. 5, the zone controller may pre- 
empt active calls and/or "borrow" call units reserved for other calls, for example, as 
has been described in relation to FIG. 2. 

15 The present disclosure therefore has identified a method of call control in a 

packet-based communication system that allows for establishing different types of 
calls, including but not limited to trunking and/or conventional calls over shared links 
of an IP network without exceeding available bandwidth. The method allows for 
service interaction between trunking and conventional calls, such that calls from one 

20 service may be busied or pre-empted, as appropriate, to ensure adequate bandwidth 
availability for the other service. 

The present disclosure has further identified methods for estabUshing static 
reservations of call counts, or call xinits of bandwidth, by a zone controller on behalf 
of other communication devices. The call coimt reservations enables the zone 

25 controller, with minimal topology information, to manage bandwidth allocations and 
Unk failures between host devices in the same or in different communication zones 
and guarantees that links will not be over-utiUzed due to excessive calls. 

The present invention may be embodied in other specific forms without 
departing from its spirit or essential characteristics. The described embodiments are 

30 to be considered in all respects only as illustrative and not restrictive. The scope of 
the invention is, therefore, indicated by the appended claims rather than by the 
foregoing description. All changes that come within the meaning and range of 
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equivalency of the claims are to be embraced within their scope. 
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1. In a conuniinication system using a packet network for distributing packets 
between endpoints for varying numbers of calls, a method comprising: 

5 determining, for one or more paths between endpoints, a corresponding one or 

more call coimts defining respective numbers of calls that are supportable by the one 
or more paths; 

receiving a call request that requires use of one or more paths; 
granting the call request if it does not exceed the call counts associated with 
10 the one or more paths. 

2. The method of claim 1, wherein the step of determining one or more call 
counts comprises: 

requesting, by a first host device of the communication system on behalf of at 
15 least a second host device of the communication system, a reservation of one or more 
call units of bandwidth for a path of the one or more paths; 

determining, by one or more network devices, an availability of the requested one 
or more call units of bandwidth for the path; and 

in response to a positive determination of availability, granting the reservation, 
20 yielding a reserved one or more call units of bandwidth for the path, 

3. The method of claim 2, wherein the first host device comprises a zone 
controller in a first communication zone, the step of requesting a reservation being 
accomplished by the zone controller on behalf of a communication device in the first 
25 commimication zone. 

4. The method of claim 1, comprising: 

detemiining, for at least one of the call counts, a first allocation reserved for a first 
type of call and a second allocation reserved for a second type of call; 
30 receiving call requests for either of the &rst and second types of calls; 

granting the call requests if they will result in a number of active calls of the first 
and second types that does not exceed the respective first and second allocations. 
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5. The method of claim 4, wherein the step of detemiining comprises determining a 
first allocation reserved for trunking calls and a second allocation reserved for 
conventional calls. 

6. A communication system comprising: 

a packet network for distributing packets between endpoints; 

a controller for determining, for at least one path between endpoints, a call count 
defining a number of calls that is supportable by the path, the call count being 
apportioned between at least a first and second type of call; and 

means for granting call requests of the first and second types of call without 
exceeding the call count. 

7. A method comprising: 

reserving, by a first host device, one or more call units of bandwidth for a path of 
a packet network communication system; 

receiving a call request that requires use of the path; 

granting the call request if a number of units of bandwidth needed for the call does 
not exceed the one or more call units of bandwidth reserved by the first 
communication device; and 

sending, firom a second host device, a message that is distributed over the number 
of units of bandwidth needed for the call. 

8. The method of claim 7, wherein the first host device is a zone controller and the 
second host device is a repeater. 

9. A method comprising: 

requesting, by a zone controller associated with a first communication zone, a 
reservation of one or more call units of bandwidth for a path of a packet network 
communication system; 

determining, by one or more network devices, an availability of the requested one 
or more call imits of bandwidth for the path; 
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in response to a positive determination of availability, granting the reservation, 
yielding a reserved one or more call units of bandwidth for the path that is available to 
support a call including participating host devices in at least the first communication 
zone. 
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10. The method of claim 9, comprising: 

receiving, by the zone controUor from a repeater in the first communication zone, a call 
request that requires use of the path; 

granting, by the zone controller, the call request if a number of units of bandwidth needed for 
the call does not exceed the reserved one or more call units of bandwidth; and 

sending, from the repeater to one or more participating devices for the call, a message 
distributed over the number of units needed for the call. 
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